A number of third-party vendors market software which provides authentication and authorization services. One example is a service that protects web-based resources. When a user enters a valid login ID and password, the authentication and authorization service retrieves the user's data from a database and displays a personalized HTML page. These authentication software packages (also referred to herein as “authenticators”) store and organize the authentication information in various datastores (databases, directories, etc). In keeping with the secure nature of the information many of the vendors use proprietary schema and/or encryption to store such information. While this provides added security to that vendor's system, it also makes it more difficult to migrate to a new vendor's product without having to have every user re-enter their security information. It is preferable for migrations to be as transparent to the end user as reasonably possible.
While the use of a Relational Data Base Management System (RDBMS) (ORACLE for example) as a datastore is very common, in other areas of programming, alternative methods do exist to the use of relational databases as datastores. One alternative is the use of flat files. Another alternative is the use of directory services. One standardized method of implementing directory services, and data store interfaces to interact with directory services, is the use of the Lightweight Directory Access Protocol version 2, the specification of which is incorporated herein by reference in its entirety. Hereinafter, when discussing this specification, it may also be referred to as LDAP version 2. LDAP version 3 also may be used and its specification is also herein incorporated by reference. LDAP is used as a generic designation for interfaces and protocols compliant with a version of the Lightweight Directory Access Protocol. For purposes of this application, by definition any server or interface which is compliant with LDAP version 3 (or a later version of LDAP) would also be viewed as compliant with LDAP version 2. The converse is not necessarily correct.
In one example, a first authenticator providing web based authentication and authorization uses a proprietary database schema built on an RDBMS as the datastore for authority for user authentications and authorizations to web protected resources (such as html pages or java applets). The desired migration is to a second authenticator which uses a directory service, preferably an LDAP-compliant directory service, as its datastore. While most of the LDAP product vendors supply toolsets or utilities that will aid in the migration from Relational Data Base Management System (RDBMS) into LDAP frameworks, these only work if the RDBMS is generic in nature. Since the first authenticator is built using a proprietary database schema, it therefore does not provide a seamless use of these tools. Specifically, the first authenticator uses a proprietary table structure (schema) and also a proprietary encryption algorithm to store the data encrypted.
A desirable feature in a security migration is to port user data out of the proprietary and/or encrypted datastore of the old authenticator into the new datastore for the new authenticator while minimizing the impact on the user experience, thereby allowing transitioning from one authenticator to the next for the protection of web resources with minimal impact to applications or users.